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(57) ABSTRACT 

A method of managing passwords of users desiring access to 
multiple target resources in a computer enterprise environ- 
ment. For each given user, each of a set of id/password pairs 
is associated to each of a set of one or more respective 
targets. Each id/password pair is normally required to access 
a respective target resource. The targets of each given user 
are stored in a globally-accessible database. In response to 
entry by a given user at a cHent machine of a single-sign on 
(SSO) id/password, the globally-accessible database is 
accessed from a personal key manager (PKM) server to 
retrieve the targets of the given user. The targets are returned 
to the PKM server, which then uses data therein to access the 
respective target resources on behalf of the given user at the 
client machine. 
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SINGLE SIGN-ON (SSO) MECHANISM 
PERSONAL KEY MANAGER 

BACKGROUND OF THE INVENTION 

1. Technical Field 

The present invention relates generally to accessing het- 
erogeneous networks and reducing costs by increasing pro- 
ductivity for end-users and system administrators in an 
enterprise computer environment. 

2. Description of the Related Art 

With sprawling client-server systems growing daily, 
applications and information are spread across many PC 
networks, mainframes and minicomputers. In a distributed 
system environment connected by networks, a user must 
access many database systems, network systems, operating 
systems and mainframe applications. To use these systems 
and applications, the user must issue separate sign-on com- 
mands for each specific system or application. Indeed, it is 
not unusual for a user to encounter ten or more different 
login sessions during a working shift, and these often are 
different interfaces with different user id and authentication 
information, usually passwords. This places the user under 
a significant burden to remember and maintain this infor- 
mation. 

It would be quite beneficial to provide a single sign-on 
(SSO) tool to enable authorized users to perform one initial 
sign-on to access a variety of networks, systems and appli- 
cations. A single sign -on system should provide secure 
storage of user passwords, support for more than one user 
password, as well as support for multiple target logon 
methods. Each of these issues present varying design con- 
siderations. 

With respect to the first issue, there are multiple 
approaches to storing and managing passwords. One 
approach is to use the same password for all accessible 
systems/applications. This technique may weaken system 
security, however, because a compromised password in any 
of the systems or applications compromises the user's 
privileges on these systems and applications at the same 
time. Further, different sign-on mechanisms may have their 
own distinctive password requirements and, thus, it is prob- 
lematic to use the same password for multiple targets. 

Another approach to storing and managing passwords is 
password-mapping, which refers to using the user's primary 
password to encrypt all the user's secondary passwords. The 
encrypted passwords are stored in a local storage space 
accessible to the tiser (e.g., a local file, a readable/writable 
smartcard, and the like). Once the primary password is 
verified, the local system authentication module obtains the 
passwords for other sign-on systems and appHcations by 
decrypting the mechanism -specific encrypted password with 
the primary password. The security of this password- 
mapping scheme assumes that the primary password is the 
user's strongest password, and it also depends on the secu- 
rity of the local storage for the secondary passwords. If 
secondary passwords are stored in an untrusted publicly 
accessible machine, an intmder is provided with opportuni- 
ties for potential attacks. Although this approach is simple, 
the password file must be moved from machine to machine 
by the user to logon to more than one machine. 

The target logon alternatives also influence the single 
sign-on system design. In particular, the method used for 
storing a user password heavily influences the design of 
target logon code. It is known to embed passwords in target 
specific logon scripts. This is how many "homegrown" 
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single sign-on systems work today. This technique is the 
least extendible design because it ties passwords (and logon 
target code) to each machine the user uses. It is also hard to 
maintain passwords in this design because passwords need 

5 to be changed both in the appHcations and in the logon 
scripts. For a mobile user, the scripts need to be present on 
all machines the user might use. The overaU security of this 
approach is thus very weak. 
Another target logon alternative involves building in all 

10 the logon methods for every possible target to which any 
user may desire to logon. This "hardcoded" approach 
assiunes that all workstations and applications are config- 
ured similarly and do not change. Because the logon meth- 
ods are built into the solution, changes made to the logan 

15 methods require changes to the actual solution itself. This 
approach is costly and also is not very extensible. 

These known approaches to secure password storage/ 
management and target logon have yet to provide an 
adequate single sign-on solution. The present invention 
addresses and solves this problem. 

BRIEF SUMMARY OF THE INVENTION 

The present invention implements a single sign-on (SSO) 
mechanism that coordinates logons to local and remote 
resources in a computer enterprise with preferably one ID 
and password. 

More specifically, this invention provides a single sign-on 
(SSO) framework that allow users to sign on to a chent 
system one time entering one password. The SSO frame- 
work then signs on to other applications on the user's behalf. 

The SSO firamework supports storage of all passwords 
and keys belonging to a user in secure storage (e.g., either 
in local storage, a centralized password service, a smartcard, 

35 or the like), so that the user needs to remember only one ID 
and password. Upon authentication, the SSO mechanism 
securely retrieves all the passwords for a user from the 
secure storage and automatically (i.e. without additional user 
intervention) issues sign-ons to each system/application the 
user is authorized to access. 

The system framework preferably includes a number of 
modules including a configuration information manager 
(CIM), which includes information on how to logon to the 
applications configured on a given machine, a personal key 

45 manager (PKM), which includes information about users, 
systems and passwords they use to logon to those systems, 
and a logon coordinator (LC), which retrieves the user's 
passwords from PKM and uses them in conjunction with 
target-specific logon code to log users onto all their systems, 

50 preferably without any additional user intervention. 

The QM facilitates adding new logon methods as needed. 
Information is preferably stored in the CIM using "tem- 
plates" referred to as program template files (PTFs). Agiven 
RTF thus is used to create entries in the CIM. This template 

55 mechanism enables an appHcation vendor to specify how to 
log on to a given apphcation. Thus, independent software 
vendors and others can easily plug their applications into the 
SSO framework without writing a large amount of code. 
The SSO framework preferably implements a "data 

60 model" where information used to sign on to applications is 
kept in the separate PKM and CIM databases. Preferably, the 
PKM is globally accessible and stores user-specific 
information, and the CIM is locally accessible and stores 
application-specific information derived firom PTF files. In 

65 operation, the logon coordinator (LC) accesses the PKM to 
obtain the user's information (e.g., which target systems and 
applications to which the user can sign -on), as well as the 
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passwords and keys for those systems/applications. The LC be implemented. The signal sign-on (SSO) mechanism com- 

then uses these passwords/keys, together with the target prises both server 20 and client (runtime services) compo- 

logon information found in the CIM, to sign-on to various nents 14, 16 and 18. For purposes of illustration, each of 

target systems and applications. Sign -on is preferably based these are illustrated as a computer. It is also assumed that 

upon the target's own protocols and mechanisms as defined 5 system users log onto the domain via client machines in a 

in the PTF. known manner. 

Another objective of this invention is to allow applica- Preferably, the server and cUent services components of 

tions to be plugged into the single sign-on (SSO) framework. mechanism are implemented in a computer or 

According to the invention, the program template file (PTF) ''^'nnn^^? ^"r^ ? ' "^^^ ' 

. , e . , . u - u /in System/6000® (a reduced mstruction set or so-called RISC- 
IS used to miorm the smgle sign-on mechanism how to lo . , i * \ • *l atv//aj ji * 

,r . ^ . „ based workstation) mnniDg the AIX ((Advanced Interactive 

mteract with a given apphcaUon or subsystem lo perform Executive) operating system, preferably Version 4 or greater. 

SSO-related operations. The PTF enables apphcations to be Alternative servers include machines running Sun Solaris V 

plugged into the SSO mechanism without changmg the SSO 2.5.1 or Microsoft Windows NT 4,0, 

code itself and without requiring any programs to be written n u a- * ^ u - a • u 

, , , ,L ^, ^. ^ ^ ^ ^ Each client machine in the domain may be a computer 

to plug mto the new application. 15 * * • i i- . 

^ ^ such as a desktop machine or laptop. A typical chent 

StUl another more general objective of this mvention is to machine is an Intel x86 or Pentium®-based computer run- 
provide a framework-type SSO mechanism that enables any Windows '95 or greater operating system. Alternatives 
kind of target to be user-specified. include machines running 0S/2(g> Warp 3.x or higher, or a 

The foregoing has outlined some of the more pertinent Microsoft Windows NT workstation. Each client worksta- 
objects of the present invention. These objects should be lion typically supports TCP/IP and may include a network 
construed to be merely illustrative of some of the more operating system (NOS). A typical client is a Novell Net- 
prominent features and applications of the invention. Many ware client (for Netware logons), an OS/2 LAN Server client 
other beneficial results can be attained by applying the (for OS/2 LAN Server logons), an OS/2 Warp Server client 
disclosed invention in a different manner or modifying the (for OS/2 Warp Server logons), or the like. These examples, 
invention as will be described. Accordingly, other objects however, are merely representative and should not be con- 
and a fuller understanding of the invention may be had by strued to limit the invention in any way. 
referring to the foUowing Detailed Description of the pre- j^any different types of target systems/applications are 
ferred embodiment. accessed using the single sign-on mechanism. These include 
BRIEF DESCRIPTION OF THE DRAWINGS 30 distributed applications, databases, printers, and other 

resources throughout the enterprise. Representative systems 

For a more complete understanding of the present inven- applications include, without limitation: 3270 and 5250- 

tion and the advantages thereof, reference should be made to ^^^^ applications, IBM OS/2 Lan Server 4.x and OS/2 

the following Detailed Description taken in connection with ^arp Server, Novell Netware 3.x and 4.x, Microsoft NT 4.0 

the accompanying drawings in which: Server, Databases (e.g., DB2, Oracle, Sybase, Informix, MS 

FIG. 1 is a computer enterprise environment in which the SQL Server), Lotus Notes 4.x, PeopleSoft applications, 

present invention may be implemented; DCE applications written to conform to The Open Group 

FIG. 2 is a block diagram of the main functional compo- (formerly known as the Open Software Foundation), and 

nents of the inventive single sign-on (SSO) mechanism; other applications. TTiese examples, again, are merely rep- 

FIG. 3 is a representative single sign -on transaction 40 rcsentative. 

according to the present invention; FIG. 2 illustrates the main components of the inventive 

FIG. 4 is a representative logon interface screen for the single sign-on (SSO) mechanism of the present invention. 

SSO transaction of FIG. 3; They preferably include an authentication module 21, a 

no. 5 is a representative GUI screen identifying the configuration information manager (CIM) 22, a personal key 

systems/appUcations for a particular user; 45 manager (PKM) 24, and a logon coordinator (LC) 26. In 

T-T-o ^ • u- i_ 1 1 -11 . r .1- r general, the authentication module 21 authenticates a given 

FIG. 6 IS a high level illustration of the operation of the * • j c .1. • 1 • l 

1 J- . /T ^\ f c^o^ L • user to the remainder of the single sign-on (SSO) mecha- 

logon coordmator (LC) of the SSO mechanism; rx . ..u 1 1 * .1. 

* ^ ' nism. On systems with local operating system secunty, the 

no. 7 is a flowchart UlustraUng the LC operation; authentication mechanism 21 usually is integrated with the 

HG. 8 illustrates how the logon coordinator performs a local OS authentication. The authentication module prefer- 

matching operation between PKM and CIM entries; ably supports different authentication mechanisms (e.g., 

FIG. 9 is a flow chart of a change password operation; secret key, smartcards, public/private key, and the like), 

FIG. 10 is a block diagram of a representative multiple The configuration information manager (CIM) 22 

SSO server implementation and a DCE Security Registry for includes information on how to logon to the applications 

supporting the PKM data model; 55 configured on a given machine. Preferably, a CIM is sup- 

FIG. 11 is a flowchart of a method for distributing and ported on each client machine from which the SSO mecha- 

synchronizing a "master key" in the multiple SSO imple- nism is provided. A given CIM typically is not globafly 

mentation of FIG. 10; accessible from other machines on the domain. Information 

FIG. 12 is a flowchart of a method for changing the master ^ CIM preferably is formatted according lo a program 

key; and 60 template file (PTF) 25, as will be illustrated below in more 

FIG. 13 is a block diagram of a known DCE domain ^^"^^ ^^^'"^^ "configuration directives" iden- 

implementation. tifying the given logon process and the methods required to 

access a particular application on the target resource. New 

DETAILED DESCRIPTION OF THE logon methods may be added using the PTF mechanism as 

PREFERRED EMBODIMENT ^5 will be seen. 

FIG. 1 illustrates a portion of a distributed computer The PKM 24 contains information about users, systems 

environment domain 10 in which the present invention may and passwords they use to logon to those systems. 
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Preferably, PKM 24 is a secure, globally accessible reposi- Target type — specifies what type of "application" the 

tory that facilitates the single sign-on process. Although not program is; 

meant to be limiting, with respect to a given user, the PKM Default target— indicates if an entry is the default of a 

(as will be described) preferably stores such information as giy^xi type; 

a useraame, a set of one or more password(s), and any other 5 „ ' . . - , - , r 

.... . . • r *• u Specific application information — describes interfaces 

application environmem-specific information such as J y . ... , , «■ j,. ,n 

j*^*^ . . • I- J 11 needed to perform operations like logon, logoff, and the like; 

domain name, hostname, application name, and the like. „ . ^. ^ . 

Because this access information preferably is centralized in ^^^^^^^ Preferences-indicates timeouts and retry 

the PKM, users can access their target resources with one ' 

sign-on from any workstation. They can also manage their jo Interface durectory-^lient-specific information on how to 

passwords from this one repository, as wiU also be seen. ^o^ate the application mterface code. 

To this end, the logon coordinator 26 functions generaUy expected runtime flow of a user interacting with the 

to retrieve the user^s passwords from the PKM and uses ^^^^ sign-on (SSO) mechanism is iUustrated in FIG, 3 and 

them in conjunction with the target specific logon code described as follows. At step 1, a user either logs in to a local 

(identifiable from the CIM entries) to log users onto all (or 15 operating system (if required by the local operating system) 

some subset of) their systems, preferably without any addi- ^^g^ °" ^ ^^go^ interface (if local logon is not required 

tional user intervention. As wiU be described in more detail operating system). A representative logon interface 

below, the LC also preferably maintains state information screen is illustrated, for example, in FIG. 4. The user's local 

for a given user and application, caUed a "user target", to ^og°° enables the authentication module (GSO Auth) on the 

help coordinate and execute future operations. 20 ^^^^^ machine (if supported) to authenticate the user (step 2) 

According to the invention, the single sign-on mechanism authemication service that is integrated with the 

preferably uses a "data model" where information used to Password storage service. 

sign on to applications is kept in two separate databases. The ^ successful authentication triggers the smgle sign-on 

first database is the PKM 24, which is preferably a global graphical user interface (GUI) to display (at step 3) the 

database and is thus accessible from all client machines in a 25 systems/appUcations the user is able to logon to and the 

given domain. The PKM 24, as noted above, keeps user ^^^^^ ^^g^" process. A representative GUI screen 

configuration information. The second database is the CIM display is illustrated in FIG. 5, The GUI also calls the logon 

22, which is preferably a local database and is thus acces- coordinator on the local machme (at step 4) to retrieve the 

sible only from the current client machine. The CIM need user's configuration inforaaation and target configuration 

not be merely a local database, however. Each chent 30 information. As described, the logon coordinator gels the 

machine from which the SSO support is provided runs a user's information (which target systems and applications 

CIM. Thus, multiple instances of CIM 22 are iUustrated in ^ignon to) and the passwords and keys for those 

FIG. 2. Likewise, each chent machine preferably also runs systems/applications from the personal key manager. If the 

an instance of the logon coordinator 26. personal key manager is implemented as a remote service 

Thus, for example, the PKM 24 contains user-specific 35 (^^ ^ ^^^^sary information is located remotely), the 

application data which includes: P^^^°^ ^7 ^ ^^^P ? g^»^ mformaUon 

™ , • 1 -J * r • m a secure fashion (i.e. the passwords/keys are encrypted for 

Target name — ^uniquely identifying a user "target ^ ■ \ t-u ^ 1 / *u *u *• 

^ * . ^« i. . „ . . transmission). The credentials remmed from the authentica- 

Taigel type-specifies what type of application this j^^dule are used by the personal key manager client to 

target is, ensure that the user who logged on to the mechanism is the 

Domain/Host/Application name^pecifies application ^ser who retrieves the passwords, 

information, specific for this target; j^^^^ coordinator (step 6) then uses these passwords/ 

User ID— specifies user id on target; ^^y^ ^nd the target logon information found in the configu- 

Key information— specifies the user's key (password) on ration information manager (CIM) to sign-on to various 

the target; target systems and applications, based upon the targets' own 

User preferences — specifies user specific information for prxDtocols and mechanisms. The logon coordinator prefer- 

this target; and ably provides status information about the state of the logons 

Preferred program name — specifies a preferred PTF entry and also allows some targets to be launched asynchronously 

to use with this target. (after the initial sign-on processing has completed). 

The personal key manager 24 enables a given SSO user to 50 This mechanism allows for different passwords for dif- 

manage all the passwords the user possesses in a secure and ferent target systems and applications without requiring the 

effective manner. According to the invention, each user to remember all such passwords. The user remembers 

application, server, or system to which a user needs an only one password to log into the mechanism, which then 

ID/password pair to logon is defined as a "target". Using a performs the subsequent logging into the different system by 

GUI interface, the user creates a target in PKM correspond- 55 acquiring the secret keys from the secured key manager 

ing to each real target to which the user can logon, and the (local or remote). This SSO mechanism enhances security as 

user may create as many (or as few) targets as the capability well as ease of use. It also enables the user to access existing 

of a specific PKM implementation allows (or that the user systems without having to create or to modify existing user 

desires). Independent of any implementation, a generic definitions on those systems. As will be seen, the mechanism 

PKM application programming interface (API) preferably is 60 also allows a user to change his or her single sign-on 

used by the SSO framework to create a new target, to update password without requiring changes of the target keys/ 

a target's data, to query a target's information (with or passwords or vice versa. Target password changes can be 

without passwords), and to delete an existing target. made to one or more selected target systems. 

The second database, the CIM 22, preferably contains FIG. 6 is a high level illustration of the operation of the 

entries derived from the program template files (PTFs). lliis 65 logon coordinator 26. FIG. 7 is a flowchart iUustrating one 

database contains application (i.e. program) specific preferred single sign-on method, which may be suitably 

information, which includes (for example): implemented in a computer program. The routine begins at 
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Step 40 when a user 30 (at a workstation 32) requests a logon nism to log onto a particular target. The free seating method 

to a given application (Target 1) 33. In response, the routine allows the user to install any program on his or her client 

continues at step 42 with the logon coordinator 26 issuing a machine and then have the logon coordinator pick the 

query to the PKM 24 for the information regarding the user's appropriate one to logon to the target. The LC preferably 

"key" (which, as described above, may include the 5 does this by examining the "target type" associated with the 

username, password, arid any other application programs on the client and with the target the user is trying 

environment-specific information as described above). At access. If the program has the same target type as the 

step 44 the information is returned to the logon coordinator. t3 j^en the LC knows it can use that program to access 

Then, the routine conUnues at step 46 with the LC issumg a ^^at target. This means that the user can logon to a target if 

query to the CIM to obtain the target information. At step 4», ,„„ „,° , ,1,. o,,,.. .1, . ,u 

,■' .. , '^. 30 any program on the system matches the target type, rather 

the target information is returned to the LC. The information ,1,' „.rj:„„ . fi„j „ ,„ j„ .l. 1 r 

. °, , , , , . , ... than needing a fixed program to do the logon, 
retneved from the CIM 22 for the particular appUcation ^ , , ,„.„™ .. 
determines how to logon to the application (e.g. what type cximpl^, a user may have a target HOSTl of type 
of invocation to make, what actual invocation, and the like). ^270 Emulator. On the machine on the user's desktop, the 
At step 52, the logon coordinator 26 substitutes given data "^^ f^,^^ ^^J^ l""^ telnet3270' program, which is of the 
received from the PKM into substimtion variables in the 'yP^ ^^TO Emulator" available to logon to HOSTl. On the 
invocation strings returned from the CIM. In particular, the "^^ '*P'°P> "sermay have the IBM Personal Corn- 
logon coordinator performs a matching operation; for each mumcator program available, which is also a 3270 Emulator, 
PKM target entry, the coordinator determines whether there '° ^ that target. When the user uses the SSO mecha- 
is a corresponding CIM entry. If so, step 52 binds the two ,„ l.'^^i'i' ''?'''°P "l"^'''"''' J£'^" "l^ telnet3270 as 
entries together. This is illustrated in FIG. 8. At step 54. the ^° '^^ ^270 Emulator to logon to HOSTl; on the laptop IBM 
logon coordinator 26 invokes the logon method(s) defined P^^'""' Communicator will be u^d Tbcse examples, of 
by and stored in the CIM. This completes the processing. «>"^' ""^^"^^^^l representative of the inventive free seat- 

Generalizing, the logon coordinator (LC) thus takes the support concept, 

data from the personal key manager (PKM) and the direc- „ The generic PKM data model described above may be 

lives in the PTF and interprets the data, together with current implemented m many ways mcluding, without limitation, 

stale information, to perform a given action. Such action is chent/server, a real smartcard, a soft (disk-based) 

carried out with respect to the users' systems and applica- ^i^^^^* smartcard, or the like. One advantage of using an 

tions and includes, for example, a logon operation, a change implementation-independent PKM API as described herein 

password operation, or a logoff operation. ^ t^at different mechanisms may be pluggable without any 

If the user requests a change password operation, the LC modification to other SSO application programs. Moreover, 
makes the correct invocation to change the password and ^^^^^^P^,^ mechanisms can be configured on one machme and 
coordinates the password update in the PKM. Continuing ^ °P^^°° ^ ^P^^^ 
with the above-described example (involving Target 1) a A representative PKM is implemented in a known DCE 
representative flowchart ofthis function is aiustrated in FIG. 35 Security Registry architecture conforming to The Open 
9. By way of brief background, the logon coordinator Group DCE Standard. Familiarity with DCE security 
preferably maintains state information for a given user and mechanisms is presumed in the following discussion, 
application, a "user target", to help coordinate and execute FIG. 10 illustrates the basic PKM architecture, which may 
future operations. By looking at the current state of a user be distributed across multiple machines in the domain. In 
target and interpreting data in the PKM entry and the PTF, 40 particular, it is first assumed that multiple SSO servers 
the LC can determine which operations are required to XQOa-n are configured and running in the domain. Multiple 
satisfy an SSO request. For example, the PTF can specify PKM servers are replicated on different machines, e.g., for 
that a user should be logged on to an application before performance and scalability. Each server preferably per- 
performing a change password operation. Therefore, the LC forms the same functions. Thus, preferably there is no 
would keep track of the logon state of a user target to 45 master/slave relationship among them. As also seen in FIG. 
determine what operations are required to satisfy a change 10, user specific target configuration data and target pass- 
password request. If the user were not logged on to the words (together, PKM data) of sso users are stored in a 
application, the LC would perform a logon operation and database, which may be the DCE extended registry database 
then perform the change password operation. (ERA). When the PKM server modifies data in the master 

The flowchart of FIG. 9 is illustrative of the process. The 50 registry, data consistency between the master and slave 

routine begins at step 60 when the user desires to change a registries is achieved automatically by the data duphcation 

password for his/her Target 1. At step 62, the routine gets mechanism in registries. However, no encryption facilities 

Target 1 information from the PKM; here, the target type is are provided by the registry for data stored in the database. 

AppL The routine then gets the corresponding program of To avoid target passwords being revealed to DCE adminis- 

the given type from the CIM at step 64. A test is then 55 trators (and others), the password field is preferably 

performed at step 66 to determine whether the user has to be encrypted with a master key managed by the PKM server, 

logged on to change his/her password. If not, the routine before the whole target is stored in the database, 

continues at step 68 and the user password is changed. If, Moreover, because the database usually does not provide 

however, the outcome of the test at step 66 is positive, a test cryptographic facilities to protect data from viewing by 

is performed at step 70 to determine whether the user is 60 other channels (like dcecp or programs using ERA API), the 

logged on. If the outcome of the test at step 70 is positive, confidentiality of target passwords is achieved by encrypting 

the routine branches to step 68; otherwise, the user is first the passwords before they are stored therein by sso servers, 

logged on at step 72. This completes the processing. To this end, a "master ke/* is preferably used to encrypt all 

A combination of the data model described and the LC the target passwords of users in sso. Further, because mul- 

implementation thus provides "free seating" support. Free 65 tiple sso servers can be configured for load balancing, a local 

seating means that the user does not have to specify a copy of this master key preferably exists in each one of sso 

particular program on the client when using the SSQ mecha- servers. 



05/06/2004, EAST Version: 1.4.1 



us 6,243,816 Bl 

9 10 

The use of a master key is advantageous even if ERA 100 server members from the keyedservers group at step 150 

provides facilities to encrypt data. A main, advantage is and, at step 152, puts itself in the group (because it is now 

performance, because only the password field, not all other the only server with a valid master key). When other servers 

user configuration fields, in a target actually needs encryp- are restarted, they will not detect themselves in the keyed- 

tioD. Using a master key outside of the database mechanism 5 servers group (as described above) and then know their 

(registry) aflfords flexibility to protect only the fields that current local copies of the master key are no longer valid, 

need encryption. Moreover, the protection level used in the ^^^X ^^^^ retrieve the new master key from the server 

existing DCE RPC service 104 to store/retrieve data member m the group, and use it to replace the old master key 

between ERA and sso servers only needs integrity, rather aescribed. 

than privacy, if passwords are akeady encrypted before they lo "taster key thus is generated automatically by one 

are sent through the RPC service ^^^^ machme and "pulled" as needed by other servers 

The inventive mechanism provides automatic master key when they are up and running A simple "group" mechanism 

distribution from one SSO ^rver to another as described PT/^^ ^ ^^^^ P^^^ 

below and as iUustrated in the flowchart of FIG. 11. ^ J? , , , ..... ^ 

Furthermore, the master key preferably is aUowed to change, is The PKM data model elements were descnbed above. The 

as initiated by sso administrators who have concerns about g^^*"?^ .^"^'"^^^ ^"f^^ ^^^S^l attributes, key 

possible key exposure. Once a new master key is generated information, user configuraUon and target class. The target 

on one server and aU the target passwords in ERA are ^I^^ identifier used to distmguish a target from other 

reencrypted, all other sso servers wiU contain invalid master V"^ ^^S^^ attributes mclude target type, domain/ 

keys. Therefore, according to the invention, master keys are 20 host/apphcation names and target user name. The key mfor- 

resynchronized among all existing servers after the master f °f password of the user for the target and 

key is modified. ^^P® °^ ^"^ derived from the password (e.g., a paibhc 

, r ,t * . key, a secret key, or the like). The user configuration is the 

Tills IS achieved as foUows. At step 110 m the flowchart, ^^.^ configxiration preference when the user logons to 

a group IS defiried m the registry to record which sso and logoffs from the target. TTie target class defines whether 

servers contain vahd master keys. The prmciples of using ^ ^ password-based target or a passticket-based 

this group and the action each sso server takes depending on ,f jj ^ pjssticket-based target, a passticket-piDtecled 

the content of this group (called keyedservers ) are elabo- ^^^ ^ j^^F) application server's name must usually be 

ra e e ow. specified. The above-described generalized data model 

At step 112 the first server is configured and started to run. 3^ enables aU kinds of targets to be defined through the PKM 
At step 114, the first server performs a test to detect where API. Thus, in certain circumstances, not all the fields/ 
it aheady has a master key copy locaUy and whether there attributes may have values for each target because only a 
exist any members in the keyservers group. If the answers to subset of attributes may be sufficient or meaningful for 
both detections are "no," the server assumes it is the first defining a specific, real target. In addition, because a pas- 
server to be configured. The routine continues at step 116 sticket for a protected server is dynamically-generated on 
with the first server generating a master key locally. At step demand, no password is required to be stored with a 
118, the first server puts itself in the keyedservers group passticket-based target. 

estabhshed at step 110 The server then starts to use the is preferably implemented as a client/server appli- 

master key (at step 120) to encrypt all the target passwords. nation on DCE. FIG. 13 is a block diagram of a known DCE 

The routine then enters a process loop for another server. 40 domain implementation. A representative DCE cell is shown 
Thus, for example, a test is done at step 122 to determine symboHcally in FIG. 13 and comprises a set of connected 
whether a second server is configured. If not, the routine machines, including at least one server and the DCE chents, 
cycles. If the outcome of step 122 is positive, the second which share a common cell name and a namespace. The cell 
server performs a similar detection scheme (like the first typically includes server machines that provide distributed 
server) at step 124. Because the first server has a master key, 45 services that support the development, use and maintenance 
the outcome ofthe test at step 124 is positive. In other words, of distributed applications in a heterogeneous networked 
this second server finds there already exists a member in the environment. These include a remote procedure call (RPC) 
keyservers group, and it thus knows the master key has Service 212, a Naming (Directory) Service 214, a Security 
aheady been generated by this member of the group (the first Service 216, a Threads Seivice 218, a Time Service 220 and 
server). The second server then continues at step 126 by 50 a Distributed File System (DFS) Service 222. As is well- 
sending a request (e.g., through an internally-defined RPC) known, the RPC Service 212 (which Ls typically not a 
to that member server to retrieve the master key. At step 128, standalone server) implements the network protocols by 
the master key is returned. The retrieved master key is then which the client and server sides of an application commu- 
stored locally in the second server at step 130. All the other nicate. The Naming Service 214 provides a central reposi- 
servers configured after the first one perform the same 55 tory for information about resources in the system. The 
actions. When any server is unconfigured as indicated at step Security Service 216 provides secure communications and 
132, it destroys its own local copy of the master key at step controlled access to resources in the system. The Threads 
134 and removes itself from the keyedservers group at step Service 218 supports the creation, management and syn- 
136. chronization of multiple threads of control within a single 

FIG. 12 is a flowchart illustrating a master key change 60 process. The Time Service 220 synchronizes time on the 

routine. It begins at step 140 when the master key is to be computers. The DFS Service 222 allows users to access and 

changed, e.g., due to security concerns. At step 142, all the share files stored on a file server anywhere in the network 

servers are stopped. At step 144, the server on which the sso without having to know the physical location of the file, 

administrator operates decrypts all target passwords in ERA The Audit Service 224 is used to write or log an audit 

102 with the old master key. A new master key is generated 65 record through Audit application programming interfaces 

at step 146, and this new master key is then used lo reencrypt (APIs). The DCE Security Service 216 includes a Registry 

target passwords at step 148. The server then removes all Service 230, an Authentication Service or AS 232, a Privi- 
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lege Service 234, an Access Control List (ACL) Facility Summarizing, single sign -on is facilitated by storing all 

236, and a Login Facility 238. The identity of a DCE user the passwords and keys belonging to a user in secure storage 

or service is verified, or authenticated, by the Authentication (either in local storage, a centralized password service, or in 

Service 232. Access to resources is controlled by comparing a smartcard), so that the user needs to remember only one ID 
the "credentials" conferred to a user by the Privilege Service 5 and password. The single sign on ID and password is then 

234 with the rights to the resource, which are specified in the "sed to authenticate the user. Upon authentication, the 

resource's Access Control List stored in Facility 236. The mechanism securely retrieves all the passwords for a user 

Login Facility 238 initiaHzes a user's security environment, fr?™.^^^ ^^^^ ^^^^^S^ automatically (without any 

preferably through a Kerberos protocol as will be discussed, additional user intervention) issues sign-ons to each appU- 

and the Registry Service 230 manages the information (such lo authorized to access, 

as user accounts) in the DCE Security database. '""^u^o^^^k?' ^'^i'^f an authentication frame- 

. ^ . , , . work that allows the PKM and the CI M implementations to 

PKM IS preferably miplemented as a chent/server appli- ^e separable from the rest of the single sign-on code. The 

cation in a distnbuted computing environment (e.g., Open functions provided by the aforementioned components are 

Group DCE) as described above. The PKM server prefer- preferably implemented via a high-level API. Thus, a new 
ably implements aU PKM functions. In this illustrative DCE 15 implementation (such as Lotus Notes) can be added without 

implementation, all target data is stored in DCE registry's causing a major redesign. This mechanism provides a logon 

ERA and the server accesses the data on behalf of each user coordination framework so that each specific target can be 

on a client machine. Therefore, the PKM API is mapped to easily plugged into the single sign-on logon coordinator 

a set of remote procedure calls (RPCs) on each chent framework. This facilitates the support of the vast range of 
machine using the DCE RPC mechanism. RPCs with dif- 20 ^i^^^^ server targets. 

ferent protection levels (e.g., privacy or integrity) and dif- x^e present invention enables efiBcient access to ihetero- 

ferent properties are employed to pass data, depending on ^^^^^^^ networks at reduced costs to thereby increase 

the API's security and semantic requirements. When the productivity for end-users and system administrators. These 

server receives a client's request, a thread is created to advantages are achieved by enabUng users to sign-on once 

access the data m the ERA, If the request is a create, update, 25 ^ ^^^j^ password to access business applica- 

or delete operation, a write to the master registry is required. ^^^^^ ^nd data. The design goals achieved are ease of use. 

If the request is a query operation, a read from any slave ^^^^ authentication of users, and logon coordination to 

registry is suflBcient to carry out the operation. If a password- multiple applications 

based target is queried, the password is retrieved from the r^u^ a « *u j 

r^T^ A ^ • • • . , • Vx^r. t n .1 in Th^ prescHt invention provides numerous other advan- 

ERA. Continuing with this DCE example, if a passticket- *„™ t* :^ Un^^^ ^ - 4 p a -j 

, ... T^w^^. , . . tages. It is based on an easy to use interface, and provides a 

based ticket IS queried, one more RPC is used to retrieve the i i, « ^ . ^ . ^ 

, . ^ , . , T^T^» M At . . consistent look and feel across operatmg systems. The tool 

secret key shared between the PKM server and the passticket • «i ^ j * • 4i. * •* • * * 

rJ_ , , . 1 . t . IS also advantageous is that it integrates with operating 

server The server then generates the passticket based on the ,^ ^^^^ ^„ standards, supports "one 

secret key and othennformation configured for the target. ^^^^^^^^ ^^^^y,^^ „f leveraging existing 

This approach provides several advantages. A framework- security infrastructures, 

based SSO mechanism as described enables aU kinds of Qne of the preferred implementations of the various 

targets to be defined for any user. Different PKM imple- ^^^^^1^5 described is as a set of instructions in a code 

mentations can be pluggable using the generic API, without ^^^^y^ ^^^^^^^^ j^e random access memory of a com- 

any changes to the programs using the PKM service. Th^ p^t^r. Until required by the computer, the set of instructions 

descnbed DCE implementation makes user authentication, ^^^y be stored in another computer memory, for example, in 

secure communication and data management much easier. ^ ^ard disk drive, or in a removable memory such as an 

Thus, according to another feature of this invention, a optical disk (for eventual use in a CD ROM) or floppy disk 

combination of the data model and the LC implementation (for eventual use in a floppy disk drive), or even downloaded 

obviates user specification of the particular program on the via the Internet. 

client when using the SSO mechanism to log on to a in addition, although the various methods described are 

particular target. Thus, the user may install any program on conveniently implemented in a general purpose computer 

the client machine, and the LC picks the appropriate one to selectively activated or reconfigured by software, one of 

logon to the target. ordinary skill in the art would also recognize that such 
One design consideration of a single sign-on system is the 50 methods may be carried out in hardware, in firmware, or in 

network authentication between a single sign-on user and more specialized apparatus constructed to perform the 

the single sign-on centralized server, and the secrecy of required method steps. 

passwords and keys transmitted across networks. These two Further, although the invention has been described in 

requirements can be achieved by utOizing the authentication terms of a preferred embodiment in a specific network 
and message encryption functions provided by any security 55 environment, those skilled in the art will recognize that the 

service, such as DCE's Kerberos or NetSP's KryptoKnight. invention can be practiced, with modification, in other and 

To make the SSO components portable to different security different network architectures with the spirit and scope of 

environments, the design and implementation of the SSO the appended claims. Moreover, the inventive diagnostic 

components should be independent of the underlying technique should be useful in any distributed network envi- 

authentication protocols and encryption mechanisms. ronment. 

The program template file (PTF) is a convenient mecha- Having thus described our invention, what we claim as 

nism for telling SSO how to interact with a given application new and desire to secure by letters patent is set forth in the 

or sub-system to perform SSO-related operations. They key following claims, 

benefit of the PTF is that it enables applications to be What is claimed is: 

plugged into SSO without changing the SSO code itself, and 65 1. A method of managing passwords of users desiring 

without requiring any programs to be written to plug into the access to multiple target resources in a computer enterprise 

new application. environment, comprising the steps of: 
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for each given user, associating each of a set of 
id/password pairs to each of a set of one or more 
respective targets, wherein each id/password pair is 
required to access a respective target resource; 

storing the targets of each given user in a globally- 
accessible database; and 

in response to a given event, accessing the globally- 
accessible database to retrieve the targets of a given 
user; 

wherein the retrieved targets are used in conjunction with 
locally-accessible logon information to access the 
respective target resources. 

2. The method of managing passwords as described in 
claim 1 wherein the given event is entry of a single sign-on 
id/password of the given user. 

3. The method of managing passwords as described in 
claim 2 further including using data in the targets to access 
the respective target resources. 

4. The method of managing passwords as described in 
claim 1 wherein each target includes a target name, a set of 
target attributes, and key information. 

5. The method of managing passwords as described in 
claim 4 wherein the set of target attributes includes attributes 
selected from the set of attributes consisting essentially of 
target type, domain name, host name, application name and 
target user name. 

6. The method of managing passwords as described in 
claim 4 wherein the key information includes the password 
of the user for the target resource. 

7. The method of managing passwords as described in 
claim 4 wherein each target further includes a user configu- 
ration identifying the user's target resource configuration 
logon/logoff preference. 

8. The method of managing passwords as described in 
claim 4 wherein each target further includes a target class 
defining additional security restrictions, if any, associated 
with the target resource. 

9. The method of managing passwords as described in 
claim 1 wherein the globally-accessible database is a DCE 
registry. 

10. The method of managing passwords as described in 
claim 1 wherein the globally-accessible database is accessed 
from a chent machine using a remotis procedure call mecha- 
nism. 

11. A method of managing passwords of users desiring 
access to multiple target resources in a computer enterprise 
environment, comprising the steps of: 

for each given user, associating each of a set of 
id/password pairs to each of a set of one or more 
respective targets, wherein each id/password pair is 
required to access a respective target resource; 

storing the targets of each given user in a globally- 
accessible database; and 

in response to entry by a given user at a client machine of 
a single -sign on id/password, accessing the globally- 
accessible database to retrieve the targets of the given 
user; 

wherein the retrieved targets are used in conjunction with 
locally-accessible logon information to access the 
respective target resources. 

12. The method of managing passwords as described in 
^ claim 11 wherein the globally-accessible database is 

accessed from a server using a remote procedure call. 

13. The method of managing passwords as described in 
claim 12 further including the steps of: 

returning the targets to the server from the globally- 
accessible database; and 
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at the server, using data in the targets to access the 
respective target resources on behalf of the given user 
at the client machine. 

14. The method of managing passwords as described in 
5 claim 11 wherein each target includes a target name, a set of 

target attributes, and key information. 

15. The method of managing passwords as described in 
claim 14 wherein the set of target attributes includes 
attributes selected from the set of attributes consisting 

10 essentially of target type, domain name, host name, appli- 
cation name and target user name. 

16. The method of managing passwords as described in 
claim 14 wherein the key information includes the password 
of the user for the target resource. 

15 17. The method of managing passwords as described in 
claim 14 wherein each target further includes a user con- 
figuration identifying the user's target resource configura- 
tion logon/logoff preference. 

18. The method of managing passwords as described in 
20 claim 14 wherein each target further includes a target class 

defining additional security restrictions, if any, associated 
with the target resource. 

19. The method of managing passwords as described in 
claim 12 wherein the step of accessing the globally- 

25 accessible database includes accessing a protected server to 
obtain information necessary to generate a passticket asso- 
ciated with the target. 

20. The method of managing passwords as described in 
claim 19 wherein the information is a secret key shared by 

30 the server and the protected server. 

21. A method of managing passwords of users desiring 
access to multiple target resources in a computer enterprise 
environment, comprising the steps of: 

for each given user, associating each of a set of 
35 id/password pairs to each of a set of one or more 
respective targets, wherein each id/password pair is 
required to access a respective target resource; 

storing the targets of each given user in a globally- 
accessible database; 

40 

in response to entry by a given user at a client machine of 
a single-sign on id/password, accessing the globally- 
accessible database from a server to retrieve the targets 
of the given user; and 
returning the targets to the server from the globally- 
accessible database; 
wherein the retrieved targets are used in conjunction with 
locally- accessible logon information to access the 
respective target resources. 
50 22. The method of managing passwords as described in 
claim 21 further including the step of: 

at the server, using data in the targets to access the 
respective target resources on behalf of the given user 
at the client machine. 
55 23. The method of managing passwords as described in 
claim 21 wherein the step of accessing the globally- 
accessible database includes accessing a protected server to 
obtain information necessary to generate a passticket asso- 
ciated with the target. 
60 24. The method of managing passwords as described in 
claim 23 wherein the information is a secret key shared by 
the server and the protected server. 

25. Personal key manager framework for managing pass- 
words of users desiring access to multiple target resources in 
65 a computer enterprise environment, comprising: 

a globally-accessible database for storing, for each given 
user, a set of targets, each target having associated 
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therewith an id/password pair required to access a 
respective target resource; 
a first program executed on a client machine in response 
to entry of a single sign-on (SSO) id/password by a 
given user for issuing a request to obtain access to the 
target resources identified in the given user's set of 
targets; and 

a second program executed on a server machine and 
responsive to the request for retrieving the targets from 
the globally-accessible database and using data in the 
retrieved targets to access the respective target 
resources on behalf of the given user at the client 
machine; 

wherein the retrieved targets are used in conjunction with 
locally-accessible logon information to access the 
respective target resources. 

26. The personal key manager framework as described in 
claim 25 further including a protected server for storing 
necessary to generate a passticket associated with a given 
target. 

27. The personal key manager framework as described in 
claim 26 wherein the information is a secret key shared by 
the server and the protected server. 

28. The personal key manager framework as described in 
claim 25 wherein the request is issued to the second program 
using a remote procedure call service. 
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29. A computer program product in a computer-readable 
media for use in a server that manages passwords of users 
desiring access to multiple target resources in a computer 
enterprise environment, wherein, for each given user, a set 
of targets is stored in a globally- accessible database, each 
target having associated therewith an id/password pair 
required to access a respective target resource, the computer 
program product comprising: 

means responsive to a given request for retrieving targets 
of a given user from the globally-accessible database; 
and 

means responsive to the retrieving means for using data in 

the retrieved targets to access the respective target 

resources on behalf of the given user; 
wherein the retrieved targets are used in conjunction with 

locally- accessible logon information to access the 

respective target resources. 

30. The computer oprogram product fast described in 
claim 29 wherein the given request is received from a chent 
machine via a remote procedure call service. 

31. The computer program product as described in claim 
29 wherein the given request is an operation selected from 
a set of operations consisting essentially of create, update, 
delete and query. 



05/06/2004, EAST Version: 1.4.1 



